Some remote data storage platforms rely on network communication such as Secure Sockets Layer (SSL) or Transport Layer Security (TLS) to ensure that client data is transmitted in an encrypted format. Other platforms support direct file encryption and either use client storage to manage asymmetric key pairs allocated on a per-user basis or envelope encryption to sign upload requests. However, such techniques have a number of shortcomings.
For example, while secure network connections can be necessary for encrypted communications between a client and a server, they can be vulnerable to a variety of Man-in-the-Middle and SSL Downgrade attacks. In such situations, supported SSL Cipher Suites need to be updated as vulnerabilities are discovered in existing protocols. In addition, other HTTP mechanisms such as Strict Transport Security and Public Key Pinning may assist in increasing the security behind SSL and TLS connections. However, ultimately any unencrypted data uploaded behind these protocols is only as secure as the network connection.
To mitigate against these vulnerabilities, some end-to-end encrypted storage platforms symmetrically encrypt data prior to uploading the data. In some cases, the keys used to encrypt the data can be stored locally. However, this method requires manual copying of the keys to access the data from a new client, and consequently, if the locally stored keys are lost, the data may be unrecoverable. Another possibility is to use asymmetric certificate signing when data is shared between clients. However, this operation requires that the symmetric key be signed by a remote server for each additional client. As a result, server processing time can be increased as new certificates must be generated each time encrypted file data is requested.
One prior art system, shown in U.S. Pat. No. 6,061,448 to Smith (Method and System for Dynamic Server Document Encryption, issued May 9, 2000), describes a delivery server that manages and coordinates asymmetric keys that are used for encrypting a symmetric data key. However, this method requires that either the encrypting client or the delivery server be responsible for forwarding the encrypted data, and key, to recipient clients, resulting in the need for management of the encrypted data, encrypted keys and recipient public keys to be by one source. Furthermore, because each recipient uses a different public key, the encrypting client must then re-encrypt the file data encryption key for each recipient, adding increased latency to the system. Another prior art system, shown in U.S. Patent Pub. No. 2015/0161409 to Szebeni (Method and system for handling of group sharing in a distributed data storage, particularly in p2p environment, published Jun. 11, 2015), uses a Key Lock Box (KLB) for storing data keys in an encrypted format. However, this system uses client bandwidth and space to distribute segments of the encrypted data across all connected peers, resulting in the availability of users encrypted file data to be contingent on the number of connected peers with access to the correct distributed segments.